1. Field of the Invention
The present invention relates to a development environment used in design and development of, e.g., system LSIs and, more particularly, to a debugging apparatus and method used in a design/development environment of system LSIs.
2. Description of the Related Art
Some applications, such as multimedia applications, require real-time processes. To achieve real-time processes, overhead due to cache refill must be avoided. For this purpose, some processors used in multimedia applications incorporate an instruction memory (to be referred to as an IMEM hereinafter) in addition to an instruction cache.
As shown in FIG. 12, a main memory comprises, e.g., a synchronous DRAM (SDRAM). This main memory has a memory size as large as, e.g., about 256 Mbits. The IMEM is a simple RAM which has a size of about several ten K bits, and allows high-speed operation since an instruction can be fetched from the IMEM within one instruction cycle.
The main memory stores program codes (to be simply referred to as codes hereinafter) each consisting of a plurality of instructions. The plurality of codes in the main memory are transferred to an overlay area of the IMEM, and are executed from the IMEM. More specifically, the IMEM is a small-size memory, as described above. For this reason, it is difficult to store the entire program in the overlay area of the IMEM. Therefore, the program is divided into a plurality of codes, which are transferred to the overlay area and are executed according to execution of the program. Hence, a code stored in the overlay area is rewritten by the latest one every time the code is transferred.
For example, when codes 1 and 2 are stored in the main memory, and code 1 is to be executed, code 1 is copied to the overlay area of the IMEM. Upon execution of code 2, it is copied to the overlay area of the IMEM. Hence, code 2 is overlaid on code 1. Therefore, instruction 1 of code 1 or instruction 2 of code 2 may be set at address A of the IMEM depending on the timings. The contents of the IMEM are replaced by a plurality of different tasks or by an identical task.
Upon debugging a program, breakpoints are frequently used as debugging means. This is a method of suspending execution when execution is about to reach that address. However, when a plurality of codes are overlaid on the IMEM, a set break command is not executed or a break command is executed erroneously in some cases. Execution of a program includes execution by a simulator and that by a real device, and a break command does not function in various cases as follows.
(1) Upon execution by simulator
Normally, an execution address of a breakpoint is saved in an internal area of a simulator, and a break occurs when the value of a program counter (PC) matches the saved address of the breakpoint. However, a plurality of codes are replaced on the IMEM, as described above. For this reason, a wrong break may occur at an address other than that at which break in a program is to take place. For example, assume that a program is to break at the address of instruction 1 of code 1 in FIG. 12. In this case, the simulator saves address A (to be referred to as execution address of instruction 1). However, if code 2 is executed prior to code 1, instruction 1 at address A is replaced by instruction 2. Hence, debugging is broken at instruction 2 of code 2. That is, a wrong break occurs at a position not intended by the programmer.
(2) Upon execution by real device
Two different break means, i.e., hard break and soft break, are available for a real device. The operation of the hard break is similar to that of the simulator. That is, the execution address of a breakpoint is saved in hardware, e.g., an address break register. The program is broken when the value of a program counter (PC) matches the address saved in the address break register. In this case, a wrong break may occur as in the simulator.
On the other hand, FIGS. 13A to 13C show an example of the soft break. In case of the soft break, a break is simulated by, e.g., rewriting the program. For example, when the program is broken at instruction 1 shown in FIG. 13A, instruction 1 is saved in a debug monitor area, as shown in FIG. 13B, and a dbreak command (an instruction that generates a debug interrupt) is set in place of instruction 1, as shown in FIG. 13C. That is, the program is rewritten from instruction 1 to the dbreak command. After the dbreak command is executed, execution of subsequent instructions is halted, and the control is transferred to a debug handler or monitor. After that, the debug handler or monitor restores instruction 1 to the original address. However, when a plurality of codes are overlaid on the IMEM, the soft break cannot often be executed.
For example, a case will be examined wherein a program is to break at instruction 1 of code 1 stored in the IMEM, as shown in FIG. 14A. In this case, instruction 1 at address A on the IMEM is replaced by the dbreak command, as shown in FIG. 14B. However, when code 2 is overlaid on code 1, as shown in FIG. 14C, the dbreak command is replaced by instruction 2. After that, when code 1 is overlaid on code 2 again, as shown in FIG. 14D, the dbreak command is removed from address A. For this reason, when the output value of the program counter reaches address A, instruction 1 is executed, and no break occurs.
As described above, since the conventional debugger cannot break a program at an address intended by the programmer, and may cause a break at a wrong address, it is difficult to efficiently debug the program. For this reason, a demand has arisen for development of a debugging apparatus and method which can reliably break a program at an address to break the program and can prevent a break at a wrong address when program codes are overlaid, and can efficiently debug the program.